Distributed process control systems, like those used in chemical, petroleum, industrial or other process plants to manufacture, refine, transform, generate, or produce physical materials or products typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog/digital buses, or via a wireless communication link or network. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and generally perform physical or process control functions such as opening or closing valves, measuring process and/or environmental parameters such as temperature or pressure, etc. to control one or more processes executing within the process plant or system. Smart field devices, such as the field devices conforming to the well-known Fieldbus protocol may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules which make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being performed in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines or links to the field devices to thereby control the operation of at least a portion of the process plant, e.g., to control at least a portion of one or more industrial processes running or executing within the plant. For example, the controllers and the field devices control at least a portion of a process being controlled by the process control system of the process plant.
Information from the field devices and the controller is usually made available over a data highway or communication network to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized administrative computing devices that are typically placed in control rooms or other locations away from the harsher plant environment. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices run applications that may, for example, enable an operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routine, modifying the operation of the control modules within the controllers or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers and field devices may include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths.
As an example, the DeltaV™ control system, sold by Emerson Process Management, includes multiple applications stored within and executed by different devices located at diverse places within a process plant. A configuration application, which resides in one or more workstations or computing devices, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which are objects in an object oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality. The viewing applications, which may be executed on one or more operator workstations (or on one or more remote computing devices in communicative connection with the operator workstations and the data highway), receive data from the controller application via the data highway and display this data to process control system designers, operators, or users using the user interfaces, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may run in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
In a process plant or process control system, when evidence of an abnormal condition or fault occurs (e.g., when an alarm is generated, or when a process measurement or actuator is found to have excessive variation), an operator, instrument technician or process engineer typically uses an analytics tool in combination with his or her knowledge of the process being controlled by the system and its flow path through the system to attempt to determine upstream measurements and process variables that may have contributed to the production of the evidence of the abnormal condition or fault. For example, an operator may feed a historical log of data that has been captured over time from the output of a process control device (e.g., a field device, a controller, etc.) into the DeltaV™ batch analytics product or continuous data analytics tool to attempt to determine the contributions of various process variables and/or measurements to an abnormal or fault condition. Typically, a user decides which historical data logs and/or other time-series data to feed into the analytics tool and identifies candidate upstream factors (e.g., measurements, process variables, etc.) based on his or her knowledge of the process. Subsequently, these data analytics tools utilize principal component analysis (PCA), or other analysis techniques such as partial least squares, linear regression, and the like, to determine which of the candidate upstream factors impact downstream predicted quality parameters. Thus, the accuracy and effectiveness of the output provided by the analytics tool is based on or limited to the user's knowledge, and as such may not provide complete or correct insight into the sources of the abnormal condition or fault.
Additionally, such analytics are typically performed off-line from the process and as such, the process may change or move while the analytics are being performed. For example, a typical process plant usually performs one or two cycles of a particular analytic (e.g., a data collection and analysis cycle) per day, and only after some time after the analytics have been performed are the results analyzed and any prescriptive actions developed and implemented in the plant. Thus, not only may the accuracy of the analytics results be suspect, but the prescriptive actions developed therefrom may not be optimal or may no longer apply to the currently executing process.
Further, the architecture of currently known process control plants and process control systems is strongly influenced by limited controller and device memory, communications bandwidth and controller and device processor capability. For example, in currently known process control system architectures, the use of dynamic and static non-volatile memory in the controller is usually minimized or, at the least, managed carefully. As a result, during system configuration (e.g., a priori), a user typically must choose which data in the controller is to be archived or saved, the frequency at which it will be saved, and whether or not compression is used, and the controller is accordingly configured with this limited set of data rules. Consequently, data which could be useful in troubleshooting and process analysis is often not archived, and if it is collected, the useful information may have been lost due to data compression.
Still further, data sets of industrial or process control plants have been steadily increasing in size to the point where present data processing analytics applications are inadequate. Typically, known analytics techniques merely attempt to extract a value from data, but do not address particular sizes of data sets from which the value is to be extracted, and notably, do not operate on very large sets of data (such as all process data that is generated by a plant) in a seamless way. Further, known analytics techniques typically cannot handle streaming or streamed data.
The limitations of currently known process plant monitoring and analytics and process control systems discussed above and other limitations may undesirably manifest themselves in the operation and optimization of process plants or process control systems, for instance, during plant operations, trouble shooting, and/or predictive modeling. Generally, real-time analytics using real-time, current industrial process performance data is not possible with known monitoring and analytics tools.